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ABSTRACT 


A  kinematic  tracker  is  a  classical  tracking  system.  The  idea  behind  kinematic 
tracking  is  to  store  positions  and  velocities  and  then,  using  this  information,  associate 
incoming  targets  with  the  stored  profiles.  Using  these  new  targets,  the  tracker  updates  its 
information  about  positions  and  velocities  to  prepare  to  do  the  entire  process  again  when  it 
is  given  the  next  set  of  targets. 
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1.  INTRODUCTION 


A  kinematic  tracker  is  a  classical  tracking  system.  The  idea  behind  kinematic  tracking  is  to  store 
positions  and  velocities  and  then,  using  this  information,  associate  incoming  targets  with  the  stored 
profiles.  Using  these  new  targets,  the  tracker  updates  its  information  about  positions  and  velocities  to 
prepare  to  do  the  entire  process  again  when  it  is  given  the  next  set  of  targets. 

This  report  discusses  kinematic  tracking  as  it  was  adapted  for  use  in  Feature- Aided  Tracking  (FAT 
[5]),  which  will  be  used  as  the  tracker  component  for  a  later  release  of  the  Integrated  Radar-Tracker 
Application  for  the  PCA  program  (initially  only  this  kinematic  tracker  will  be  used).  An  overview  of  this 
entire  application  can  be  found  in  [3]  and  discussion  of  the  Ground  Moving  Target  Indicator  (GMTI)  radar 
component  being  used  is  contained  in  [7].  This  report  was  mainly  derived  from  a  tracker  implementation 
and  its  documentation  by  L.  Keith  Sisterson,  but  includes  modifications  made  by  Duy  Nguyen  for  the  FAT 
system  as  well. 

1.1  KINEMATIC  TRACKING— HIGH  LEVEL  DESCRIPTION 

A  tracker  will  receive  information  from  the  GMTI  system  regarding  new  target  detections.  On  the 
radar  side  this  is  often  referred  to  as  the  detection  list.  FAT  and  the  kinematic  tracker  it  was  built  upon  refer 
to  these  either  as  measurements  or  target  reports.  These  target  reports  make  up  half  of  the  input  to  a  tracker. 
The  other  half  of  the  input  comes  from  the  tracker  itself,  these  being  the  tracks  which  were  its  output  from 
the  previous  scan.  The  track  histories  are  referred  to,  and  drawn,  as  a  loop-back  input  as  opposed  to 
persistent  data;  this  reference  is  done  for  two  reasons.  The  first  reason  is  that  radar  is  a  streaming 
application,  and  the  output  comes  in  discrete  bursts  (each  burst  referred  to  as  a  scan).  Trackers  then  are 
often  thought  of  similarly  because  they  are  part  of  an  overall  radar  system  (even  though  they  are  arguably 
closer  to  thread-based  than  stream-based  computation).  The  second  reason  is  that  the  track  history  for  scan 
n  is  the  result  from  scan  n-I,  and  drawing  it  as  a  loop-back  system  highlights  this.  A  common  reference 
used  in  the  remainder  of  this  report  will  be  a  “track/report  pair.”  Pairing  a  track  and  a  report  means  that  the 
report  is  considered  to  be  the  next  part  of  the  track.  A  tracker  must,  in  some  manner,  consider  all  possible 
track/report  pairs  to  determine  the  continuation  of  the  tracks. 

1.1.1  Kinematic  Tracking  Overview 

The  diagram  in  Figure  1  is  a  convenient  way  to  conceptualize  the  basic  tasks  which  a  kinematic 
tracker  must  perform.  Figure  1  diverges  from  the  actual  algorithm  in  that  the  stages  of  “Hypothesize 
Associations,”  “Extrapolate  Tracks,”  and  “Compute  Kinematic  )(  ”  cannot  so  conveniently  be  separated 
in  a  serial  fashion.  In  the  process  of  hypothesizing  associations,  one  must  extrapolate  tracks  along  different 
movement  models  and  compute  a  kinematic  %  value  for  each.  In  this  report,  four  movement  models  are 
discussed;  greater  or  fewer  could  be  used  as  is  appropriate  for  the  specific  application.  The  meanings  of 
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these  three  steps  will  be  explained  separately,  but  the  algorithmic  implementations  are  too  closely 
intertwined  to  separate  and  will  be  treated  together. 


Figure  1.  Kinematic  tracker  logical  diagram. 


Hypothesizing  associations  considers  all  track/report  pairs  and  determines  which  have  a  possibility 
of  being  correct  associations.  First,  it  will  be  considered  if  the  pairing  is  possible.  Then  all  possible 
pairings  will  need  to  be  extrapolated  along  some  number  (three  for  this  example)  of  known  movement 
hypotheses  and  an  unmodeled  maneuver  hypothesis.  Then  these  extrapolations  must  be  judged  to 
determine  which,  if  any,  gives  the  most  likely  manner  in  which  the  specific  target  report  could  be  the 
continuation  of  the  specific  track.  The  metric  used  to  ^etermine  this  (also  the  overall  likelihood  that  a 
track/report  pair  is  a  correct  pairing)  is  the  kinematic  %  value  (where  smaller  %  values  indicate  greater 
likelihood).  The  Munkres  algorithm  is  a  method  for  finding  the  optimal  assignment  of  tracks  to  reports 
given  a  matrix  of  their  %  values.  A  Kalman  filter  is  then  used  to  update  the  tracks  to  take  their  newly 
associated  target  reports  into  account. 
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A  track  itself  is  simply  a  manner  of  keeping  track  of  an  object  across  scans.  Objects  may  stop  and 
begin  moving  again  or  move  in  and  out  of  the  area  of  interest,  so  the  notion  of  beginnings  and  endings  of 
tracks  needs  to  be  dealt  with  (note  that  this  may  not  be  the  case  in  the  initially  distributed  data  set,  but  false 
detections  and  indistinguishable  targets  will  still  make  this  necessary).  To  deal  with  a  track  beginning, 
tracks  are  separated  into  three  different  kinds  of  tracks:  New,  Novice,  and  Established.  A  New  track  is  a 
track  that  is  just  starting  and  has  only  the  initial  target  report  associated  with  it.  Upon  receiving  another 
associated  target  report,  a  New  track  will  become  a  Novice  track.  A  track  is  considered  a  Novice  track  as 
long  as  any  Doppler  ambiguity  exists.  (Doppler  ambiguity  will  be  discussed  in  the  next  paragraph)  Once 
the  Doppler  ambiguity  of  a  track  has  been  eliminated,  it  becomes  an  Established  track.  Tracks  are  removed 
when  a  certain  period  of  time  or  number  of  scans  has  passed  with  no  further  associations  to  update  them. 
This  would  logically  take  place  as  part  of,  immediately  before,  or  immediately  after  the  Kalman  filtering 
stage. 

The  phenomenon  of  Doppler  ambiguity  rises  because  the  measurements  of  Doppler  frequency  which 
the  MTI  stage  makes  are  modulo  the  pulse  repetition  frequency  (PRF).  This  means  that  two  targets  that 
differ  in  Doppler  frequency  by  an  integer  multiple  of  the  PRF  will  be  seen  as  having  the  same  Doppler 
frequency.  Note  that  if  a  target  has  a  Doppler  frequency  equal  to  an  integer  multiple  of  the  PRF,  it  may 
have  already  been  filtered  out  by  the  MTI  stage  as  a  stationaiy  object.  In  Introduction  to  Airborne  Radar 
(Chap.  25,  [8])  low  PRFs  are  given  to  be  250-4000  Hz,  medium  PRFs  to  be  10-20  kHz,  and  high  PRFs 
1 00-300  kHz.  The  choice  of  PRF  relies  on  many  factors,  but  generally  a  Ground  Moving  Target  Indicator 
(GMTI)  radar  (which  is  the  MTI  portion  of  this  integrated  radar-tracker  application)  will  use  a  low  or 
medium  PRF,  and  is  therefore  subject  to  Doppler  ambiguity  issues.  The  tracker  needs  to  know  the  Doppler 
frequency  to  calculate  the  velocity  of  a  target,  so  it  needs  to  know  with  greater  precision  than  modulo  the 
PRF.  There  are  various  ways  to  deal  with  Doppler  ambiguities;  however,  they  all  require  state  information, 
so  this  will  be  the  job  of  the  tracker  in  this  implementation.  For  more  information  on  Doppler  ambiguities, 
see  section  “Potential  Doppler  Ambiguities”  on  page  284  of  Introduction  to  Airborne  Radar  [8].  (The  case 
of  “PRF  Less  Than  Spread  of  Doppler  Frequencies”  applies  to  this  discussion.) 
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1.1.2  Hypothesize  Association,  Extrapolate  Tracks,  Compute  Kinematic  % 

While  these  three  logical  operations  cannot  be  readily  separated  algorithmically,  it  is  algorithmically 
possible  to  separate  them  into  two  stages.  The  first  stage  looks  at  all  track/report  pairs  and  uses  geographic 
location  to  eliminate  impossibilities.  The  next  stage  examines  each  remaining  track/report  pair  individually 
to  first  eliminate  kinematic  impossibilities  and  then  determine  the  correct  motion  model  and  %  value  for 
possible  pairings. 

1.I.2.I  Reduce  By  Geographic  Position 

A  sizeable  amount  of  computation  is  done  on  each  track/report  pair  which  is  being  considered  by  the 
rest  of  the  algorithm.  The  purpose  of  this  step  is  to  eliminate  geographically  impossible  pairings.  Ground 
vehicles  can  be  assumed  to  have  a  low  enough  velocity  that  they  will  not  move  too  great  a  distance 
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between  scans.  Using  the  report  position,  track  position,  and  postulated  maximum  ground  vehicle  speed, 
only  certain  track/report  pairs  will  be  possible,  so  all  others  can  be  ignored.  This  implementation  will 
geographically  check  all  tracks  for  each  incoming  target  report. 

1. 1.2.2  Examine  One  Track/Report  Pair 

For  each  target  report,  each  track/report  pair  considered  geographically  possible  by  the  previous  step 
will  be  tested.  First  an  unmodeled  maneuver  model  will  be  extrapolated  to  determine  if  the  track/report 
pair  is  kinematically  possible,  and  if  possible,  then  a  %  -like  value  will  be  calculated  (for  all  track/report 
pairs  deemed  geographically  or  kinematically  impossible,  the  %  value  assigned  is  an  arbitrary  value  large 
enough  to  prevent  the  Munkres  algorithm  from  choosing  it  over  a  viable  association  and  no  other 
hypotheses  are  tested).  Now  the  method  of  dealing  with  each  pair  diverges  depending  upon  the  status  of  * 

the  track.  For  New  or  Novice  tracks,  Doppler  ambiguity  is  checked,  and  the  %  -like  value  from  the 
unmodeled  test  is  saved  for  this  pair.  For  Established  tracks,  the  track  is  extrapolated  in  three  manners: 
constant  velocity;  linear  acceleration;  and  constant  speed,  arc^of  circle.  Each  hypothesis  for  track 
extrapolation  will  be  considered  in  the  order  above  and  yield  a  %  value.  Each  will  also  have  a  separate 
limit  for  consideration  and  use  this  to  determine  success  or  failure.  If  a  motion  model  succeeds,  the  model 
name  and  are  saved.  In  the  case  of  failure,  the  next  motion  model  is  checked.  After  all  models  are 
exhausted,  the  'l  -like  value  from  the  unmodeled  test  will  be  stored  and  “unmodeled”  will  be  stored  as  the 
motion  model  name.  If  the  scan  times  are  close  together  in  time,  most  motion  will  be  seen  as  constant 
velocity.  Note  that  the  number  and  type  of  hypothesized  motion  models  is  dependent  upon  the  application, 
and  more  or  less  could  be  used. 

1.1.3  Munkres  Algorithm 

The  Munkres  algorithm  [4]  is  a  method  of  uniquely  associating  things,  one  with  another,  while 
minimizing  a  cost  function.  The  cost  function  is  used  to  populate  a  matrix  of  all  possibilities.  The  Munkres 
algorithm  then  chooses  associations  by  choosing  exactly  one  member  of  each  row  and  column  such  that 
the  sum  of  the  chosen  elements  is  minimized.  In  a  kinematic  tracker,  the  Munkres  algorithm  is  one  option 
to  use  to  decide  which  reports  will  be  assigned  as  the  successors  of  which  tracks.  The  original  algorithm 
requires  a  square  input  matrix  and  will  associate  all  items.  An  extended  version  of  this  algorithm  [1]  is 
used  here  as  it  will  work  on  non-square  matrices  and  associates  as  many  items  as  the  minimum  of  rows  and 
columns.  The  matrix  passed  in  is  made  of  the  kinematic  %  (or  merged  %  for  FAT)  values.^Recall  that, 
for  track/report  pairs  determined  to  be  geographically  or  kinematically  impossible,  a  large  %  value  will 
have  been  used  to  prevent  their  selection  if  any  other  possible  choices  are  available.  The  Munkres 
algorithm  will  perform  all  optimal  pairings,  then  will  continue  pairing  those  intended  as  impossible 
afterward.  Additional  checks  have  been  added  to  be  sure  no  impossible  pairings  are  passed  to  the  Kalman 
filter  as  being  associated. 
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1.1.4  Kalman  Filtering 

A  Kalman  filter  is  a  classical  way  to  update  knowledge  with  measurements.  The  idea  behind  a 
Kalman  filter  is  that  any  measurement  has  an  associated  uncertainty.  Different  measurements  may  have 
different  uncertainties.  By  using  multiple  measurements  and  taking  their  respective  uncertainties  into 
account,  a  more  accurate  estimate  may  be  made.  It  would  be  impractical  to  store  each  and  every 
measurement,  especially  considering  that  the  total  number  of  measurements  may  be  neither  known  nor 
likely  to  be  few.  The  Kalman  filter  deals  with  this  by  taking  two  separate  measurements  with  two  separate 
errors.  Using  this  information,  it  determines  a  new  estimate  based  on  both  measurements,  which  will 
presumably  be  a  better  estimate  than  either  measurement  separately.  The  Kalman  filter  will  also  determine 
an  error  for  the  new  estimate.  In  this  way,  only  one  former  state  need  be  saved,  and  each  new  measurement 
is  simply  applied  to  the  aggregate  history  and  a  new  aggregate  history  is  formed.  In  the  kinematic  tracker, 
a  Kalman  filter  is  used  to  update  the  track  histories  with  their  new  target  reports.  An  intuitive  explanation 
of  Kalman  filtering  can  be  found  in  [6],  and  a  more  rigorous  description  can  be  found  in  [2].  (Section  5.5  of 
[2],  “The  discrete  Kalman  filter,”  starting  on  p.  214  discusses  a  Kalman  filter  similar  to  the  one  used  in  this 
tracker  in  greater  depth  than  covered  here.) 

1.2  PARAMETERS 

This  section  explains  parameters  which  are  needed  as  inputs  and  controls  for  the  operation  of  the 
kinematic  tracker.  The  output  values  are  also  discussed.  Because  the  tracker  works  as  a  loop-back  system, 
it  will  be  taken  as  understood  that  the  output  for  one  stage  is  also  the  input  of  the  next,  and  outputs  will  not 
be  listed  twice  below. 

1.2.1  Input  Parameters 

There  is  really  only  one  external  input,  the  target-report  list.  The  target-report  list  will  be  signified  by 
the  one-dimensional  array  M  [  ] ,  each  element  of  which  will  be  a  structure.  M  [  ]  will  have  a  member 
structure  named  cent  (short  for  centroid).  The  target-report  list  will  be  what  will  populate  cent  in  the 
appropriate  member  of  M  [  ] .  Table  1  outlines  the  data  members  of  the  elements  of  cent  which  need  to  be 
populated  before  passing  them  to  the  tracker.  Shaded  elements  are  data  members  used  by  later  stages  of  the 
overall  FAT  algorithm,  but  not  by  kinematic  tracking.  Note  that  cent  was  based  upon  the  input  structure 
used  in  the  system  this  tracker  was  based  upon,  and  a  different  input  structure  is  used  by  the  GMTI  system 
attached  here. 
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TABLE  1 

Pre-Populated  Data  Members  of  cent 


m 

rg 

Range  position  of  target.  This  is  used  primarily  to  determine  ground 
position. 

az 

Azimuth  position  of  target.  This  is  used  primarily  to  determine  ground 
position. 

dop 

Doppler  measurement  for  target.  This  is  used  primarily  to  measure  the 
target’s  radial  velocity. 

time 

Time  stamp  for  when  this  detection  was  made. 

snr 

Signal-to-noise  ratio  (SNR)  of  detection.  This  is  a  measure  of  the  reiative 
strength  of  the  target  detection. 

;.hrr 

High  range  resolution  (HRR)  profile  for  target.  j;  fc  i 

1.2.2  Output  Parameters 

The  output  is  also  composed  of  a  structure.  It  is  the  list  of  tracks  recognized  by  the  kinematic  tracker. 
The  track  list  will  be  signified  by  the  one-dimensional  array  T  [  ] .  The  purpose  of  the  track  list  is  two-fold. 
One  is  as  output  to  a  user;  the  other  is  as  loop-back  input  to  the  tracker.  Table  2  outlines  the  data  members 
of  the  elements  of  T  [  ]  which  are  used  outside  the  current  scan  with  the  kinematic  tracker.  Shaded 
elements  are  data  members  not  of  direct  interest  to  a  human  user,  but  are  used  either  in  the  loop-back  input 
or  in  other  sections  of  the  overall  FAT  algorithm. 
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TABLE  2 

Pre*Populated  Data  Members  of  t  [] 


snr 

SNR  of  last  target  report  associated  with  this  track.  This  is  a 
measure  of  the  relative  strength  of  that  target  detection. 

X 

Estimated  x-coordinate  of  target  at  time  time. 

y 

Estimated  y-coordinate  of  target  at  time  time. 

x_dot 

Estimated  velocity  of  target  in  the  x  direction  at  time  time. 

y_dot 

Estimated  velocity  of  target  in  the  y  direction  at  time  time. 

time 

Time  stamp  for  the  last  target  report  associated  with  this  track. 

■{New,  Novice, 'Established}  ”■  ' 

Classification  vectbf  from  o\^rall  FAT  cbniiSutations^l  V  |i|  i 

iE|fi^|ted^sp||i|ijgl|:;.of;tatflS|ftime^^^ 

9Hi 

^jl^^l^ld  bi^c^®!)ise^cb^|bh6e 

^ypothesis  - 

Movement  model  hypofliesized  for  last  track/report  association  for 

1.2.3  Control  Parameters 

There  are  multiple  control  parameters.  In  the  implementation  these  will  be  part  of  a  structure  (see 
Section  3.4).  However,  a  structure  is  not  necessaiy,  so  for  the  algorithm  they  will  be  treated  as  separate 
values.  Parameters  important  to  the  algorithmic  description  or  general  conceptual  understanding  are  listed 
in  Table  3. 
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TABLE  3 

Control  Parameters  for  Kinematic  Tracker 


MM 

MaxNumReports 

Maximum  number  of  target  reports  allowed  (necessary  only  for 
worst-case  analysis  or  memory  restrictions  of  actual 
implementation).  This  parameter  is  not  used  in  the  Matlab 
implementation. 

MaxNumTracks 

Maximum  number  of  tracks  allowed  (necessary  only  for  worst-case 
analysis  or  memory  restrictions  of  actual  implementation).  This 
parameter  is  not  used  in  the  Matlab  implementation. 

maxSpeed 

Assumed  maximum  possible  speed  for  a  target. 

maxAccel 

Assumed  maximum  possible  acceleration  for  a  target. 

RVar 

Variance  in  range  measurement  from  GMTI  stage. 

AzVar 

Variance  in  azimuth  measurement  from  GMTI  stage. 

DopVar 

Variance  in  Doppler  measurement  from  GMTI  stage. 

CVHLimit 

Limit  used  to  test  constant  velocity  hypothesis. 

LATHUmit 

Limit  used  to  test  linear  acceleration  hypothesis. 

ArcHLimit 

Limit  used  to  test  constant  speed,  arc  of  circie  hypothesis. 

cvsq 

Used  to  compute  process  noise  covariance  matrix  for  constant 
velocity  hypothesis. 

latsq 

Used  to  compute  process  noise  covariance  matrix  for  linear 
acceleration  hypothesis. 

mnsq 

Used  to  compute  process  noise  covariance  matrix  for  constant 
speed,  arc  of  circle  and  unmodeled  hypotheses. 

Limit  to  how  long  a  New  track  is  kept  if  not  updated. 

Limit  to  how  long  a  Novice  track  is  kept  if  not  updated. 

EstablishedLimit 

Limit  to  how  long  an  Established  track  is  kept  if  not  updated. 

GrIdXNearRatio 

Ratio  to  define  the  concept  of  a  track  being  “near”  a  target  report  in 
the  X  direction  for  geographic  decimation. 

GridYNearRatio 

Ratio  to  define  the  concept  of  a  track  being  “near”  a  target  report  in 
the  Y  direction  for  geographic  decimation. 

PlafformXPos 

X  position  of  radar  platform  by  the  XY  grid  used  for  targets  (Y 
position  of  platform  is  0). 
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2.  FUNCTIONAL  OVERVIEW 


This  section  will  cover  the  base  functionality  required  by  the  kinematic  tracker.  Only  the  general 
required  functionality  of  a  kinematic  tracker  is  discussed  here.  The  methods  in  this  section  for  performing 
operations  are  generalizations  of  what  is  necessary  and  required  for  the  operations,  and  may  not  be 
reflections  of  the  Matlab  implementation.  This  is  done  to  hopefully  help  highlight  areas  open  to  new 
implementations  to  take  advantage  of  PCA  hardwares’  unique  characteristics.  The  section 
“Implementation  Considerations”  will  contain  some  discussions  about  basic  performance  improvements. 
Functions  which  act  as  translators  between  systems,  parameter  filters,  and  other  implementation  “glue,” 
though  necessary,  are  not  discussed  in  this  report. 

In  this  section  (and  throughout  the  report)  C++-style  pseudocode  is  used,  although  Matlab  code  is 
provided  for  implementing  this  tracker.  This  was  chosen  mainly  to  avoid  the  potential  confusion  of 
variable  types  in  Matlab. 

2.1  HYPOTHESIZE  ASSOCIATION,  EXTRAPOLATE  TRACKS,  COMPUTE  KINEMATIC 

These  three  stages  are  once  again  divided  along  the  lines  of  an  initial  decimation  by  geographic 
position  and  then  an  examination  of  each  remaining  track/report  pair. 

2.1.1  Reduce  By  Geographic  Position  [get_tracks_near  ( )  ] 

Input:  This  operation  requires  as  input  the  track  list  T  [  ]  and  target  report  list  M  [  ] .  The  sizes  of  these 
lists  will  vary  from  scan  to  scan;  however,  they  may  be  bounded  by  MaxNumTracks  and  MaxNumReports. 

Output:  The  output  of  this  operation  is  logically  a  boolean  association  matrix  Assoc.  Assoc  will 
be  of  size  txm,  where  t  is  the  number  of  elements  in  T  [  ]  and  m  is  the  number  of  elements  in  M  [  ] . 

All  track/report  pairs  must  be  examined.  Later  stages  may  perform  large  computations  for  each 
track/report  pair  that  must  be  operated  upon.  This  stage  acts  as  a  first  cut.  The  conceptual  algorithm  for 
doing  this  is  as  follows: 

for(int  i=0;  i<length(M) ;  ++i) 
for(int  j=0;  j<length(T);  ++ j ) 
if  (near  (M[i]  ,T[j]  )  ) 

Assoc  [j]  [i]=true; 
else 

Assoc  [j]  [i]=false; 
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The  function  length  ( )  is  considered  to  return  the  number  of  elements  of  the  array  which  it  is 
passed  as  input.  The  function  near  ( )  returns  a  boolean  value  indicating  if  the  input  target  report  is 
sufficiently  close  to  the  input  track.  The  actual  definition  of  near  ( )  is  unimportant  to  the  algorithm  as 
long  as  it  always  returns  true  when  the  track/report  pair  is  a  correct  association.  A  function  always 
returning  true  would  be  acceptable  for  the  algorithm.  Discussions  on  the  concept  of  being  geographically 
near  and  on  efficiency  can  be  found  in  the  section  “Implementation  Considerations.” 

2.1.2  Examine  One  Track/Report  Pair  [associate  ( )  ] 

Input:  This  operation  will  require  the  track  list  T  [] ,  target  report  list  M  [] ,  and  boolean  association 
matrix  Assoc.  Assoc  is  of  size  txm  where  t  is  the  number  of  elements  in  T  [  ]  and  m  is  the  number  of 
elements  in  M  [  ] .  The  number  of  elements  in  T  [  ]  and  M  [  ]  will  vary  from  scan  to  scan;  however,  they  may 
be  bounded  by  MaxNumTracks  and  MaxNumReports. 

Output:  The  output  of  this  operation  will  be  a  possibly  modified  boolean  association  matrix  Assoc, 
a  chosen  hypothesis  matrix  Hyp,  and  a  matrix  of  the  calculated  kinematic  X  values  Kin_X2.  All  three  of 
these  matrices  will  be  of  size  txm  where  t  is  the  number  of  elements  in  T  [  ]  and  m  is  the  number  of 
elements  in  M  [  ] . 

This  process  will  loop  over  all  track/report  pairs.  If  it  finds  in  Assoc  that  the  pair  has  already  been 
marked  false,  then  the  equivalent  entiy  in  Kin_X2  will  be  set  to  a  suitably  large  value  to  avoid  being 
considered  viable  by  Munkres  (100  chosen  for  Matlab  code).  If  the  pair  has  been  marked  true,  then  an 
unmodeled  test  will  take  place.  The  unmodeled  test  computes  a  limit  on  the  distance  between  the  target 
report  and  the  extrapolated  position  of  the  track.  The  limit  to  determine  if  the  unmodeled  test  is  passed 
corresponds  to  nine  times  the  variances  from  all  the  sources  of  error  plus  the  distance  the  target  could  move 
(from  the  initial  track  position)  if  it  accelerated  at  maxAccel.  If  the  unmodeled  test  fails,  then  Assoc  is 
modified  to  mark  this  pairing  as  impossible  and  Kin_X2  is  set  to  the  same  large  value  as  it  would  had  it 
failed  previously.  If  it  passes,  then  a  -like  value  is  computed,  made  too  large  to  be  chosen  in  place  of  a 
modeled  association,  and  saved. 

2  . 

For  New  or  Novice  tracks,  Unmodeled  is  saved  in  Hyp  and  the  unmodeled  %  is  saved  in  Kin_X2. 
Doppler  ambiguity  is  also  examined,  but  the  results  do  not  alter  execution  of  this  stage. 

For  Established  tracks,  the  unmodeled  test  will  have  been  calculated  with  slight  differences  to  take 
more  knowledge  into  account.  The  primary  difference  is  in  the  use  of  the  plant-noise  matrix  Q.  The  plant- 
noise  matrix  is  dependent  upon  the  difference  in  time  between  the  target  report  and  last  track  update  and  a 
parameter  g  (full  definition  of  Q  can  be  found  in  Section  2.3).  For  an  Established  track,  the  unmodeled  test 
uses  a  Q  with  q  equal  to  one-third  the  square  of  maxAccel.  After  passing  the  unmodeled  test,  an  Established 
track  tests,  in  order,  the  constant  velocity  hypothesis,  the  linear  accelerating  track  hypothesis,  and  the  arc- 
of-circle  hypothesis. 
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2. 1.2.1  Constant  Velocity  Hypothesis 

The  track  extrapolation  for  this  hypothesis  is  the  same  as  the  unmodeled  computation  but  with  a 
different  plant-noise  matrix  Q.  For  the  constant  velocity  hypothesis,  the  parameter  cvsq  is  used  for  q  in 
forming  Q.  The  main  difference  is  that  an  actual  %  is  computed  as  follows: 


2 


X 


1  9  2 


(1) 


where  d  isa  Doppler  value,  r  is  the  radial  distance  between  the  extrapolated  track  and  target  report,  and  <5 
is  the  variance.  The  value  of  is  calculated  as  follows: 


<7^  _  - - 

r 

2 

The  calculated  %  is  then  tested  against  parameter  CVHLimit.  If  it  is  within  the  limit,  then  constant 
velocity  is  saved  in  Hyp  and  the  %  is  saved  in  Kin_X2.  If  it  is  outside  the  limit,  then  the  next  Hypothesis 
is  tested. 


2.  L  2. 2  Linear  A  ccelerating  Track  Hypothesis 

2 

The  track  position  and  %  are  extrapolated  as  follows: 


xt 

=  Xp+Xt^  — 


(3) 


xyt 

2x 


2 

1  = 


{x  +  xt)  sin  a  +  ■~J  cos  a  - 

^  2  ^  ~2 

^d+^d, 


(4) 

(5) 


2  .  .  . 

There  are  two  tests  for  success  here.  The  first  is  to  test  that  the  %  is  within  the  confidence  limit 
parameter  LATLimit.  The  second  is  to  make  certain  that  the  acceleration  computed  from  a  least-squares  fit 
of  the  target-report  position  to  the  extrapolated  track  position  above  is  not  greater  than  the  parameter 
maxAccel.  If  both  of  these  tests  are  passed,  then  linear  accelerating  track  is  saved  in  Hyp  and  the  %  is 
saved  in  Kin_X2.  If  either  test  fails,  the  next  hypothesis  is  tested. 
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2. 1.2.3  Constant  Speed  Arc-of-Circle  Track  Hypothesis 

The  arc  of  a  circle  is  constructed  from  the  track  position  and  direction  compared  to  the  current  target 
2 

report.  %  is  calculated  as  follows: 


2  {xtS.\na+y,cosa-d^)  ^  {yt-sf 


(6) 


/T2  ^  2  2 

where  v  =  fjx  +y  (speed  of  the  target),  5  =  distance  along  arc  of  circle,  =  variance  of  v,  and  = 

variance  of  s.  The  only  test  performed  is  %  against  the  parameter  ArcLimit.  If  the  test  is  passed,  constant 

speed,  arc-of-circle  is  saved  in  Hyp  and  the  %  is  saved  in  Kin_X2. 


If  all  three  of  these  models  fail,  then 
2 

unmodeled  %  -like  value  is  saved  in  Kin_X2. 


Unmodeled  is  saved  in  Hyp 


and  the  previously  saved 


2.2  MUNKRES  ALGORITHM  [MUNKRES  ( )  ] 

Input:  This  general  algorithm  only  requires  the  matrix  of  %  values  Kin_X2  (or  the  merged 
FAT_X2  if  FAT  is  being  used).  To  easily  include  checking  for  geographically  or  kinematically  impossible 
assodations,  the  boolean  association  matrix  Assoc  will  also  be  passed  as  input.  The  size  of  these  matrices 
is  /  X  /w ,  where  t  is  the  number  of  elements  in  T  [  ]  and  w  is  the  number  of  elements  in  M  [  ] .  The  number 
of  elements  in  T[]  and  M[]  will  vary  from  scan  to  scan;  however,  they  may  be  bounded  by 
MaxNumTracks  and  MaxNumReports. 

Output:  The  output  is  an  optimal  list  MunkresResult  []  of  chosen  track/report  pairings.  The 
elements  of  the  list  will  be  tuples  indicating  the  pairing.  This  list  will  include  unassociated  tracks  and 
unassociated  target  reports  as  being  associated  with  a  null  value  (this  implementation  used  -1  for  this  null 
value).  The  size  of  the  list  may  be  at  worst  t  +  mand  at  best  max(/,  m),  where  t  is  the  number  of  elements  in 
T  [  ]  and  m  is  the  number  of  elements  in  M  [  ] . 

The  following  is  quoted  directly  from  pages  803  and  804  of  [1].  In  the  paper,  the  original  Munkres 
algorithm  is  first  listed,  then  changed  steps  are  listed  for  the  extended  Munkres  algorithm.  In  the  interests 
of  clarity,  quotes  of  the  steps  from  the  original  algorithm  are  being  substituted  in  the  paper  where  they 
belong  in  the  quote  of  the  extended  version. 
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"The  statement  of  the  extended  algorithm  follows. 

Preliminaries,  (a)  k  =  min  (n,  m) ,  no  lines  are  covered,  no 
zeros  are  starred  or  primed,  (b)  If  the  number  of  rows  is  greater 
than  the  number  of  columns,  go  at  once  to  step  0.  Consider  a  par¬ 
ticular  row  of  the  matrix  (a^^)  ;  subtract  the  smallest  element  from 
each  element  in  the  row;  do  the  same  for  all  other  rows.  If  the 
number  of  columns  is  greater  than  the  number  of  rows,  go  at  once  to 
step  1 . 

Step  0.  (c)  For  each  column  of  the  resulting  matrix,  subtract 
from  each  entry  the  smallest  entry  in  the  column. 

Step  1.  Find  a  zero,  Z,  of  the  matrix.  If  there  is  no  starred 
zero  in  its  row  nor  its  column,  star  Z.  Repeat  for  each  zero  of  the 
matrix.  Go  to  step  2. 

Step  2.  Cover  every  column  containing  a  0*.  If  Jc  columns  are 
covered,  the  starred  zeros  form  the  desired  independent  set .  Oth¬ 
erwise,  go  to  step  3. 

Step  3.  Choose  a  noncovered  zero  and  prime  it;  then  consider 
the  row  containing  it.  If  there  is  no  starred  zero  Z  in  this  row, 
go  to  step  4.  If  there  is  a  starred  zero  Z  in  this  row,  cover  this 
row  and  uncover  the  column  of  Z.  Repeat  until  all  zeros  are  cov¬ 
ered.  Go  to  step  5, 

Step  4 .  There  is  a  sequence  of  alternating  starred  and  primed 
zeros  constructed  as  follows:  let  Zq  denote  the  uncovered  O'.  Let 
Z^  denote  the  0*  in  Z's  column  (if  any).  Let  Z2  denote  the  O'  in 
Z]^ '  s  row.  Continue  in  a  similar  way  until  the  sequence  stops  at  a 
O',  Z2]^,  which  has  no  0*  in  its  column.  Unstar  each  starred  zero  of 
the  sequence,  and  star  each  primed  zero  of  the  sequence.  Erase  all 
primes  and  uncover  every  line.  Return  to  step  2. 

Step  5.  Let  h  denote  the  smallest  noncovered  element  of  the 
matrix;  it  will  be  positive.  Add  h  to  each  covered  row;  then  sub¬ 
tract  h  from  each  uncovered  column.  Return  to  step  3  without  alter¬ 
ing  any  asterisks,  primes,  or  covered  lines." 


Note  that  the  above  algorithm  terminates  through  step  2.  The  result  MunkresResult  []  will  be 
generated  by  using  the  coordinates  of  the  zeros  of  the  resultant  matrix.  The  Munkres  algorithm  may  have 
chosen  geographically  or  kinematically  impossible  associations  where  no  possible  association  was 
available.  To  eliminate  these,  each  response  pair  will  be  tested  against  Assoc.  If  a  pairing  is  found  which 
is  marked  impossible  within  Assoc,  then  the  original  pair  will  be  replaced  by  two  new  pairs,  with  each 
element  of  the  first  pair  paired  with  some  sort  of  null  value  (-1  is  used  in  the  provided  Matlab  code).  After 
the  entire  MunkresResult  [  ]  list  is  checked,  then  the  matrix  result  from  the  actual  Munkres  algorithm 
will  be  examined  for  rows  or  columns  containing  no  zero  (which  must  exist  if  the  matrix  is  not  square). 
The  equivalent  tracks  or  target  reports  will  each  be  appended  to  the  list  in  a  new  tuple  with  the  null  value  as 
their  partner. 

2.3  KALMAN  FILTERING  [Kalman  ( )  ] 

Input:  This  operation  will  require  as  input  the  optimal  pairing  list  MunkresResult  [] ,  the  track 
list  T  [  ] ,  and  the  target  report  list  M  [  ] .  The  size  of  an  element  of  MunkresResult  [  ]  is  the  size  of  two 
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references  (integer  index,  pointer,  or  whatever  else  might  be  convenient  for  the  given  implementation),  and 
the  length  of  the  list  is  at  worst  t  +  m  and  at  best  max(t,  m),  where  t  is  the  number  of  elements  in  T  [  ]  and 
m  is  the  number  of  elements  in  M  [  ] .  The  number  of  elements  in  T  [  ]  and  M  [  ]  will  vary  from  scan  to  scan; 
however,  they  may  be  bounded  by  MaxNumTracks  and  MaxNumReports. 

Output:  The  updated  track  list  T  []  is  the  output.  The  length  of  T  []  will  vary  from  scan  to  scan. 
Recall  that  an  actual  Kalman  filter  is  run  only  on  Established  tracks,  so  the  Kalman  filter  itself  will  not 
change  the  size  of  T  [  ] .  The  additional  step  of  creating  new  tracks  with  unassociated  target  reports  will 
increase  the  size  of  T  [  ] ,  and  the  possible  removal  of  tracks  not  updated  in  a  certain  specified  time  will 
decrease  the  size  of  T  [  ] ,  so  the  output  and  input  sizes  of  T  [  ]  need  not  match.  The  size  can  still  be 
considered  bounded  by  MaxNumTracks  though. 

For  New  tracks,  covariance  matrices  are  initialized  and  relevant  initial  information  is  stored.  For 
Novice  tracks,  velocity  windows  are  examined  to  determine  if  there  is  enough  information  to  resolve 
Doppler  ambiguity.  If  there  isn't  enough  information,  the  target  report  is  saved.  Once  there  is  sufficient 
information,  then  the  state  is  set  to  Established  and  the  Kalman  filter  is  recursively  run  on  all  previously 
saved  target  reports  (in  chronological  order)  and  then  on  the  current  one  (the  maximum  set  in  the  original 
code  is  five  saved  target  reports  plus  the  current  one).  For  Established  tracks,  an  actual  Kalman  filter  will 
be  performed.  A  description  of  the  operation  in  matrix  notation  (along  with  matrix  definitions)  is  below. 
Note  that  the  subscript  k  indicates  the  current  scan,  so  k-1  indicates  the  most  recent  prior  scan: 

The  true  current  state: 


1)  The  current  target  report  can  then  be  represented  as  follows: 

+ noise 


(where  = 


10  0  0 
0  0  10 
0  sino  0  cosar 


with  a  =  azimuth  angle) 


2)  The  initially  extrapolated  next  state  for  the  track: 

3)  The  error  covariance  matrix  for  the  initially  extrapolated  next  state: 

T 


Pk  = 


1  +  ^, 


k-\ 


(7) 

(8) 


(9) 

(10) 
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4)  The  Kalman  gain  stage  1 : 


(11) 


(where  Hj^  = 


10  0  0 
0  0  10 


5)  The  error  covariance  matrix  is  then  updated: 


Pk  =  U-  'Kj^k^P'k 


(where  = 


10  0  0 
0  0  10 


) 


6)  The  extrapolated  track  covariance  matrix  is  set  to  the  updated  track  covariance  matrix: 

,+ 


7)  The  Kalman  gain  stage  2; 


Pk-Pk 


(where =  [o  sin  a  0  cos  a]  with  o  =  azimuth  angle) 

8)  The  final  error  covariance  update: 


(where =  [q  sina  0  cosa]  with  a  =  azimuth  angle) 

9)  The  state  estimate  update: 

xl  =  xl  +  K,llI-BK^Ut-H^,]] 


(where  = 
with  a  =  azimuth  angle) 


10  0  0 

0  0  0  0 

1  0  0 

0  0  10 

,B  = 

0  0  0  0 

,  and  X  = 

0  1  0 

0  sina  0  cosa 

0  sin<3  0  cos  a 

_0  0  0 

(12) 


(13) 


(14) 


(15) 


(16) 
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The  meanings  or  definitions  of  the  other  matrices  are  as  follows: 


or 


X 

•  y 

d 


^k-\ 


P'k  or  P'1 


Qk-i  = 


where  x  and  y  are  coordinate  positions  and  x  and  y  are  velocities  in  the 
respective  coordinate  directions.  These  are  members  x,  x_dot,  y,  and  y_dot, 
respectively,  of  elements  of  T  [  ] . 


where  x  and  y  are  coordinate  positions  and  d  is  the  velocity  in  the  radial  direction.  These  are 
members  x,  y,  and  dop,  respectively,  of  elements  of  M  [] . 


1/00 
0  10  0 
0  0  1/ 
0  0  0  1 


where  /  is  the  time  between  the  target  report  and  last  track  update. 


p,  p,  p,  p, 
P2  P5  P<.  Pi 
P3  Pe  P^  P9 
P4  P-]  Pg  P\o_ 


Pi  is  referred  to  as  Pm  and  as  Pp.  These  are  stored  as  members  of 
elements  of  T  [  ] .  These  are  covariance  matrices  for  the  updated  states 
generated  by  the  Kalman  filter. 


qt^ 

0 

0 

3 

2 

,.2 

2 

qt 

0 

0 

3 

2 

0 

0 

qt 

qt 

3 

2 

2 

0 

0 

qt 

2 

qt 

where  /  is  the  time  between  the  target  report  and  last  track  update  and  q  is 
a  constant  dependent  upon  the  motion  model  last  chosen  to  describe  track 
movement.  This  is  stored  as  member  Q  of  elements  of  T  [  ] . 
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is  the  target  report  measurement  covariance  matrix.  It  is  calculated  using  the  MTI 
results  and  the  parameters  RVar,  AzVar,  and  DopVar,  which  would  be  taken  from  the 
MTI’s  system  specifications.  It  is  stored  as  member  R  of  elements  of  M  [  ] . 


is  calculated  and  used  within  the  Kalman  filter.  It  is  stored  as  member  K1  of  elements 
ofT[]. 


calculated  and  used  within  the  Kalman  filter.  It  is  stored  as  member  K2  of  elements  of 

[]. 


/ :  identity  matrix  of  appropriate  size  for  computation. 

After  this  computation,  (the  estimated  position  for  the  track)  is  the  nominal  result,  and  Xj^  and 
are  stored  for  use  in  the  next  iteration.  The  above  steps  1-10  describe  a  Kalman  filter.  Other 
computations  listed  in  this  section  are  related  in  purpose  for  the  kinematic  tracker,  but  are  not  actually  part 
of  a  Kalman  filter.  The  Kalman  filter  portion  may  be  extracted  for  reuse  in  FAT  for  the  intermediate 
deliverable.  All  track/report  pairs  for  FAT  will  be  extrapolated  with  a  Kalman  filter  and  their  aspect  angle 
will  then  be  estimated  (discussed  in  Appendix  A). 

It  should  be  noted  that  only  elements  x,  x_dot,  y,  y_dot,  status,  and  Pp  of  elements  of  T  [  ] 
are  updated  by  the  above  operations.  To  fully  update  a  track,  the  other  required  elements  (snr,  time, 
class,  aspect,  hrr,  and  Hypothesis)  are  directly  replaced  by  the  value  belonging  to  the  target 
report  that  the  track  was  just  associated  with. 

The  final  step  which  needs  to  be  performed  to  update  the  track  list  is  to  examine  each  track  in 
MunkresResult  [  ] ,  which  is  paired  with  a  null  value.  The  time  member  of  the  track  will  be  compared 
against  the  time  member  on  target  reports  in  the  current  scan.  If  this  difference  is  larger  than  that  allowed 
in  the  limit  for  tracks  of  its  status  (parameters  NewLimit,  NoviceLimit,  and  EstablishedLimit),  then  the 
track  is  removed.  If  McaNumTracks  is  exceeded,  then  tracks  may  be  removed  by  a  chosen  policy.  One 
policy  might  be  to  decrease  the  time  allowed  for  waiting  on  associations  before  being  removed.  Another 
might  be  to  remove  the  tracks  with  the  lowest  snr.  Note  that  the  Matlab  code  delivered  does  not  actually 
use  a  MaxNumTracks  value,  so  no  tracks  will  be  dropped  by  the  Matlab  code  for  this  reason. 
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3.  DATA  STRUCTURES 


A  variety  of  data  structures  are  used  in  the  tracker.  Below  is  a  discussion  on  the  initial  proposition  for 
their  specific  structure.  The  definitions  will  be  given  in  a  C  style  (note  that  in  C  pointers  are  generally  used 
to  declare  dynamically  resizable  arrays). 

3.1  TARGET  REPORTS 

The  structure  for  target  reports  is  a  simple  structure,  the  global  list  of  which  has  been  referred  to  as 
M  [  ]  in  this  report.  The  centroid  structure  will  contain  the  information  from  the  MTI  report  which  will  be 
saved  in  the  target  report.  Additional  information  (such  as  the  cosine  of  the  azimuth  angle)  is  stored  in  this 
structure  for  convenience. 


struct  target_report 
{ 

struct  centroid  cent; 

double  Range; 
double  Azimuth; 
double  Doppler; 

double  sin_az; 
double  cos_az; 
double  sdsqd; 
double  abs_dop; 
double  R  [2]  [2]  ; 


} 


//contains  original  info  passed  in 
//  from  MTI 

//These  three  parameters  are  the 
//  ground  values  of  rg,  az,  &  dop 
//  in  cent  (the  values  in  cent  may 
//be  absolute  or  may  be  indices) . 
//sine  of  the  azimuth  angle 
//cosine  of  the  azimuth  angle 
//doppler  variance  (in  m/s) 
//corrected  doppler  (in  m/s) 
//measurement  (x,y)  covariance 
//  matrix 
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struct  centroid 

{ 

int  rg ; 
int  az ; 
int  dop ; 
double  time; 


//range  gate  index  or  absolute 
//  range  in  meters  for  this  target 
//beam  index  or  absolute  azimuth 
//  angle  in  radians  for  this  target 
//doppler  bin  index  or  absolute 
//  doppler  in  m/s  for  this  target 
/ /time  stamp  associated  with  this 
//  target 

//SNR  for  this  target 


double  snr; 

//double  hrr[hrr_size]; 

//will  be  introduced  for  FAT. 

//vector  containing  the  HRR 
//  profile  for  this  target 
//additional  members  to  be  populated  by  the  tracker 
//  all  this  information  should  be  redundant  with  the 
//  above  info. 

double  x;  //x  coordinate  of  this  target 

double  y;  //y  coordinate  of  this  target 

} 


3.2  TRACK 

The  track  structure  is  a  simple  structure,  the  global  list  of  which  has  been  referred  to  in  this  report  as 
T  [  ] .  This  structure  is  used  both  as  output  and  input,  though  only  a  subset  of  the  structure  is  required  in  the 
following  scan. 
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struct  track_history 
{ 


char  status  []  ; 

//string  containing  status 

double 

x_pos ; 

//  (enum  should  be  used  in 
//  compiled 
//  implementation) 

//x  coordinate  of 

double 

y_pos ; 

//  estimated  position  of 
//  track 

//y  coordinate  of 

double 

X  vel; 

//  estimated  position  of 
//  track 

//estimated  x  direction 

//  velocity  of  track 

double 

y_vel ; 

//estimated  y  direction 

double 

snr  ; 

//  velocity  of  track 
//snr  from  last  associated 

double 

time ; 

//  target 

//time  from  last  target 

//  double  hrr[hrr_size]; 

//will  be  introduced  for  FAT. 

/ /YncTC  from  last  target 

//  struct  classification  class; 

//will  be  introduced  for  FAT. 

//prior  classification 
//  vector,  computed  by 
//  Bayesian  classifier. 

//  double  aspect; 

//will  be  introduced  for  FAT. 

//estimated  aspect  angle 
//  of  track  in  radians 

//represents  different 
//  possible  actual 
//  doppler  values,  used  in 
/ /  resolving  doppler 
//  ambiguity. 


/ /additional  members 
struct  VelWindow  vwt5] ; 
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struct  CVHFilter  cvhf; 

struct  target_report  Msave 
char  Hypothesis  []  ; 

double  Q  [4]  [4]  ; 
double  Pm  [4]  [4]  ; 
double  Pp[4]  [4]  ; 
double  K1 [4]  [2]  ; 
double  K2 [4]  [1]  ; 

} 

struct  VelWindow 

{ 

int  active; 

double  xdot ; 
double  ydot; 
double  xdotvar; 

double  ydotvar; 

double  xydotvar; 

} 

struct  CVHFilter 

{ 

double  x; 
double  y; 
double  xdot ; 
double  ydot; 

} 


//Abstraction  from 
//  original  system,  may  be 
/ /  removed . 

[5]  ; //saves  old  targets  for 

//  New/Novice  tracks  until 
//  they  become  established 
//string  containing 
//  hypothesis  (enum  should 
//be  used  in  compiled 
//  implementation) 
//process  noise  covariance 
/ /  matrix 

//initial  extrapolation 
//  covariance  matrix 
//updated  extrapolation 
//  covariance  matrix 
//Kalman  gain  stage  1 
//  matrix 

//Kalman  gain  stage  2 
//  matrix 


//indicates  state  of  this 
//  velocity  window 
//x  direction  velocity 
//y  direction  velocity 
//variance  in  x  direction 
//  velocity 

//variance  in  y  direction 
//  velocity 

//covariance  between  x  and 
//  y  velocities 


//x  coordinate 
//y  coordinate 
//x  velocity 
//y  velocity 
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3.3  ASSOCIATION  MATRICES 


These  matrices  are  simply  IXm  matrices,  where  t  is  the  length  of  the  global  track  list  for  the  current 
scan  and  m  is  the  length  of  the  global  target  report  list  for  the  current  scan.  Because  the  sizes  of  these  lists 
may  change  from  scan  to  scan,  the  dimensions  of  these  matrices  also  may  change.  There  will  be  three  or 
five  matrices  of  this  size.  For  simple  kinematic  tracking,  the  matrices  are  Assoc,  Hyp,  and  Kin_X2.  For 
FAT,  the  additional  matrices  CAT_or_SAT_X2  and  FAT_X2  are  also  used  (though  Kin_X2  will  be 
copied  to  FAT_X2  in  simple  kinematic  tracking).  A  dynamically  resizable  matrix  in  C  is  represented  by  a 
double  pointer.  Because  a  string  in  C  is  usually  represented  by  a  char*,  a  matrix  of  strings  will  be 
represented  as  a  triple  pointer.  A  matrix  of  arrays  would  also  be  represented  as  a  triple  pointer. 

bool  **Assoc;  //T/F  matrix  based  on  geographic 

/ /  feasibility 

char*  **Hyp;  //matrix  of  strings  keeping  track 

//of  which  hypothesis  was  last 
//  chosen  (enum  should  be  used  in 
//  compiled  implementation) 
double  **Kin_X2;  //contains  X'^2  values  for 

//  kinematic  tracker 

double  **CAT_or_SAT_X2 ;  //contains  X^2  values  for  CAT  or 

//  SAT  (whichever  is  used) 
double  **FAT_X2;  //contains  final/merged  X*2 

//  values. 
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3.4  TRACKER  PARAMETERS 


This  simple  structure  holds  the  control  parameters  used  for  the  tracker.  These  will  be  set  by  an 
initialization  function  and  perhaps  never  changed  after  that, 
struct  TrackerParameters 

^bool  UsingExact;  //specifies  if  centriods  report 

//  absolute  or  index  values. 

double  SpeedOf Light ;  //Make  sure  all  parts  of  IRT 

//  use  same  approximation. 

long  MaxNumReports;  //maximum  number  of  reports 

//  considered 

long  MaxNumTracks ;  //maximum  number  of  tracks  kept 

//the  following  four  parameters  are  used  to  determine 
//  how  far  a  target  may  move  between  scans. 

double  maxSpeed;  //maximum  speed  considered 

//  (m/s)  • 

double  maxSpeedsqd;  //maxSpeed*maxSpeed 

double  maxAccel;  //maximum  acceleration 

//  considered  (m/s''2) 

double  maxAccelsgd;  //maxAccel*maxAccel 

//the  following  three  parameters  are  used  to 
//  formulate  measurement  covariance  matrix  R 

double  InvalidChiSqd;  //Chi  squared  value  to  indicate 

//  impossible  pairing 

dox±>le  MaxPosDiff;  //Maximum  possible  difference 

/ /  between  target  report  and 
//  unmodeled  extrapolation 

int  NumAzBins;  //The  number  of  azimuth  bins 

//  used  by  GMTI 

double  TotalAzCoverage;  //Total  azimuth  coverage  of 

//  GMTI  in  radians. 

double  AzDegPerBin;  //The  degree  extent  of  one 

//  azimuth  bin 

long  NumRangeBins ;  //The  number  of  range  bins  used 

//by  GMTI 

int  NumDopBins;  //The  number  of  doppler  bins 

//  used  by  GMTI 

double  DopMpSPerBin;  //The  coverage  (in  m/s)  of  one 

//  doppler  bin. 
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//the  following  three  parameters  represent  how  often 
//  pulses  are  sent  and  what  percentage  of  the  time  is 
//  spent  transmitting. 

double  PRF;  //Pulse  Repetition  Frequency- 

double  PRI ;  //Pulse  Repetition  Interval 

double  DutyCycle;  //Percentage  spent  transmitting 

double  CPI;  //Number  of  pulses  collected 

//by  GMTI  for  one  data  cube 

double  CPIDuration;  //Time  between  receipt  of  scans 

//  for  the  tracker  (minimum  is 
//  CPI  *  PRI) 

double  ScenarioTotalTime ; //Time  entire  scenario  takes 
double  DeAlias;  //used  to  de-alias  Doppler 

//  measurements 

double  ExpSNR;  //Expected  SNR  for  targets,  for 

//  use  in  calculating  variances 
//  theoretically 

double  PerfectRVar;  //variance  used  for  range  in 

//  truth  data 

double  PerfectAzVar ;  //variance  used  for  azimuth  in 

/ /  truth  data 

double  Perf ectDopVar ;  //variance  used  for  Doppler  in 

//  truth  data 

//  Note  that  the  below  variances  may  be  set  either  as 
//  theoretically  derived  or  statistically  derived 
//  variances.  Statistically  derived  variances  are  used 
//  for  the  delivered  implementation, 
double  RVar;  //variance  on  range  measurement 

double  AzVar;  //variance  on  azimuth 

//  measurement 

double  DopVar;  //variance  on  doppler 

/ /  measurement 

//the  following  three  parameters  are  used  to  test  if 
//  the  corresponding  hypothesis  is  correct, 
double  CVHLimit;  //Test  limit  for  Constant 

//  Velocity  Hypothesis 

double  LATHLimit;  //Test  limit  for  Linear, 

/ /  Accelerating  Track 
//  Hypothesis 

double  ArcHLimit;  //Test  limit  for  Arc  of  Circle 

//  Hypothesis 
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//the  following  three  parameters  are  used  for  the 
//  values  of  q  in  computing  the  process  noise 
//  covariance  matrix  Q. 


double  cvsq; 


double  latsq; 


//mean  square  acceleration 
//  plant  noise  for  constant 
//  velocity  hypothesis 
//mean  square  acceleration 
//  plant  noise  for  linear, 
//  accelerating  track 
//  hypothesis 


double  mnsq;  //mean  square  acceleration 

//  plant  noise  for  arc  and 
//  unmodeled  hypothesis 

//the  following  three  parameters  are  used  to  decide 
//  how  long  a  track  may  be  kept  without  an  update, 
double  NewLimit;  //Time  limit  for  New  tracks 

double  NoviceLimit;  //Time  limit  for  Novice  tracks 

double  EstablishedLimit ;  //Time  limit  for  Established 


//  tracks 

double  PlatformHeight ;  //Height,  in  meters,  of 

//  stationary  radar  platform 

double  PlatformXPos;  //X  position  of  radar  by  the  XY 

//  grid  used  with  targets  (Y 
//  position  is  0) 

//the  following  six  parameters  are  used  for  the 
//  simple  geographic  grid  structure  being  used  in  the 
//  Matlab  code.  Others  would  be  used  for  different 
//  geographic  schemes. 

double  GridEltXSize;  //X  width  of  one  element  of  the 


double  GridEltYSize ; 
double  GridXWidth; 
double  GridYWidth; 
double  GridXNearRatio; 


//  grid 

//Y  width  of  one  element  of  the 
//  grid 

//X  width  of  entire  grid  (must 
//  accommodate  radar  scan) 

//Y  width  of  entire  grid  (must 
//  accommodate  radar  scan) 
//Ratio  to  determine  nearness 
//  in  X 
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double  GridYNearRatio; 
double  MinTimeExtent ; 
double  RangeMultiplier ; 


} 


//Ratio  to  determine  nearness 
//  in  Y 

//Minimum  time  within  PRI 
//  before  GMTI  may  receive. 
//Used  in  determining  range  for 
//  range  bin  to  absolute  range 
//  calculation. 
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3.5  EXTRAPOLATED  TRACK  POSITIONS 


This  data  stnicture  is  a  simple  container  for  track  extrapolations.  A  vector  could  be  used  instead,  if 
desired. 


struct  ExtrapolatedTrackPosition 


{ 

double  x; 
double  y; 
double  xdot ; 
double  ydot ; 
double  Doppler; 

} 


//x  coordinate  position 
//y  coordinate  position 
//x  direction  velocity 
//y  direction  velocity 
//radial  direction  velocity 


3.6  MUNKRES  RESULT 

This  is  a  simple  vector  of  integer  tuples  (or  a  two  column/row  matrix  of  integers)  giving  back 
associated  track/report  pairs  as  each  element.  The  length  of  this  vector  will  fluctuate  not  only  with  the 
number  of  tracks  and  reports  in  a  given  scan,  but  also  with  the  results  of  the  Munkres  algorithm.  If  all  new 
reports  are  geographically  too  far  away  from  all  existing  tracks  to  be  possibly  the  same,  then  the  length  of 
the  vector  would  be  the  Num  Reports  +  Num  Tracks,  whereas  the  case  where  all  reports  and  tracks  might 
possibly  be  associated  would  result  in  max(Num_Reports,  Num_Tracks)  tuples. 

struct  tuple  //struct  for  readability 

{ 

int  pair [2];  //holds  a  track/report 

/ / association 

} 

struct  tuple  *MunkresResult ;  //dynamically  allocate  the 

//  number  of  these  tuples 
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4.  IMPLEMENTATION  CONSIDERATIONS 


The  major  portion  of  implementation  considerations  examined  by  this  report  is  related  to  the  process 
of  reducing  the  number  of  track/report  pairs  using  geographic  information.  This  particular  area  is  focused 
on  because  its  results  determine  the  difficulty  of  the  rest  of  the  computation  (save  for  Kalman  filtering). 

The  simple  loop  method  listed  in  Section  2.1.1  for  geographic  reduction  is  obviously  an  expensive 
way  to  do  geographic  reduction  and  is  not  preferred.  A  more  desirable  method  would  be  to  use  a  custom 
structure  to  accept  queries.  Perhaps  the  simplest  structure  which  can  be  used  is  a  grid.  A  grid  would  simply 
be  a  matrix  of  track  reference  lists  corresponding  to  locations  on  the  ground.  Every  target  report  would  fall 
within  some  grid  element;  the  track  lists  from  that  grid  element  and  grid  elements  sufficiently  close  would 
then  all  be  returned  as  the  possible  tracks.  The  coarseness  of  this  can  be  adjusted  with  the  size  of  grid,  the 
element,  and  the  method  for  determining  which  other  grid  spaces  are  near  enough  to  the  target.  More 
complex  database  methods  could  also  be  used.  A  more  complex  idea  would  be  to  use  two  indices;  one 
sorted  along  x  position  and  the  other  along  y  for  the  track  list.  A  query  could  then  give  a  position  and  a 
distance  from  that  position,  and  a  range  select  could  be  performed  on  both  lists  and  the  intersection  of  the 
results  returned.  Other  methods  might  also  present  themselves  from  a  specific  parallel  design. 

The  choice  for  geographic  reduction  methods  is  a  careful  trade-off.  It  is  done  to  save  computation, 
but  using  too  complex  a  method  will  simply  waste  computation.  Because  there  is  a  second  round  of 
elimination  with  the  unmodeled  test,  it  does  not  make  sense  to  choose  a  method  more  complicated  than 
performing  the  unmodeled  test  on  all  potential  track/report  pairs.  Where  more  target  detections  are 
expected  or  the  probability  of  false  alarms  is  high,  this  method  becomes  more  important.  Recall  also  that 
extra  target  reports  may  enlarge  the  computational  load  both  present  and  future,  as  they  will  be  added  as 
new  tracks  for  the  next  scan. 

Another  concern  for  processing  load  is  frequency  of  tracks  missing  some  number  of  target  report 
associations.  Tracks  will  be  dropped  if  enough  time  goes  by  with  no  additional  associations,  but  they  are 
not  dropped  immediately.  The  problem  which  arises  is  that  the  last  estimated  position  of  the  correct  track 
will  be  significantly  farther  away  from  the  target  report  than  would  be  expected  for  the  normal  case.  The 
simplest  solution  for  this  is  to  keep  the  geographic  reduction  fairly  coarse.  A  more  complex  solution  might 
be  to  keep  separate  structures  for  tracks  depending  upon  when  they  were  last  updated  or  to  include 
elements  of  time  in  the  database  query  capabilities. 

The  Matlab  implementation  will  use  a  simple  grid  method  for  this  computation.  The  test  of  nearness 
will  be  as  follows:  if  a  target  is  within  a  certain  ratio  of  the  space  of  the  grid  element  from  one  border 
(specified  by  parameters  GridXNearRatio  and  GridYN ear  Ratio),  then  the  neighboring  element  will  be 
considered.  If  two  neighboring  elements  are  being  considered,  then  the  diagonal  element  between  them 
will  also  be  considered.  This  grid  method,  with  appropriate  grid  element  size  and  nearness  ratios,  will  be 
considered  coarse  enough  that  tracks  which  have  missed  updates  will  still  be  within  the  returned  list  of 
possible  tracks.  This  operation  will  be  encapsulated  in  the  function  get_tracks_near  ( ) ,  so  with  only 
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the  change  in  this  function  and  the  update  function  [update_track_locations  { )  ]  an  alternate 
method  can  be  used. 

Another  location  which  might  easily  accept  optimizations  is  the  MunkresResult  []  list.  It  may 
be  decided  to  not  include  tracks  when  associated  with  null  (or  reports  or  even  both).  This  would  reduce  the 
immediate  amount  of  data  needed  to  be  passed  around,  but  the  information  about  which  tracks  and  reports 
are  unassociated  is  needed  eventually,  so  it  would  need  to  be  determined  again  in  some  manner. 


f 
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APPENDIX  A 

ASPECT  ANGLE  ESTIMATION 


Using  the  assumption  that  the  radar  platform  is  stationary  at  coordinates  (0,0),  aspect  angle 
estimation  can  be  performed  in  the  following  manner; 


0  =  acos 


t-v 
M  X|v 


(17) 


COS0  sin0 
-sin0  COS0 


(18) 


cos  a  = 


rt 
r\  X  1/| 


(19) 


If  cosa-  1  is  smaller  than  a  tolerance  limit  (10  ^  used  in  code),  then  0  will  be  returned  as  the 
aspect  angle.  Should  this  limit  fail,  then  27t  -  0  will  be  returned  as  the  aspect  angle. 


Note  that  the  radar  is  actually  at  position  {PlatformXPos,  0),  not  the  origin,  so  appropriate  translation 
must  be  performed  on  the  coordinates. 


31 


ACRONYMS 


FAT  -  Feature-Aided  Tracker 
SAT  -  Signature-Aided  Tracker 
CAT  -  Classification-Aided  Tracker 
MTI  -  Moving  Target  Indicator  [radar] 

GMTI  -  Ground  Moving  Target  Indicator  [radar] 

PRF  -  Pulse  Repetition  Frequency 
SNR  -  Signal-to-Noise  Ratio 

CONVENTIONS 

The  courier  font  is  used  for  programming  code/pseudocode  and  also  quotations  (with  a  reduced 
font  size). 
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